10장. AI 기능을 서비스에 붙이는 방식

1. AI 기능은 챗봇만 있는 것이 아니다

AI를 서비스에 붙인다고 하면 가장 먼저 챗봇을 떠올리기 쉽다.

사용자가 질문을 입력하고,
AI가 답변하는 화면을 만드는 방식이다.

하지만 실제 서비스에서 AI는 챗봇보다 훨씬 다양한 형태로 들어갈 수 있다.

예를 들어 다음 기능들을 생각해보자.

- 고객 문의 내용을 자동으로 요약한다.
- 신고 내용을 위험도별로 분류한다.
- 관리자 메모를 정리한다.
- 상품 설명이나 공지문 초안을 만든다.
- 번역 결과를 자연스럽게 다듬는다.
- 장애 로그를 보고 원인 후보를 정리한다.
- PR 내용을 요약한다.
- 회의록에서 액션 아이템을 뽑는다.

이 기능들은 모두 AI를 사용하지만, 형태는 조금씩 다르다.

어떤 기능은 사용자가 직접 AI와 대화한다.
어떤 기능은 버튼을 누르면 AI가 결과를 만들어준다.
어떤 기능은 백그라운드에서 자동으로 실행된다.
어떤 기능은 사람이 검토한 뒤에만 최종 반영된다.

그래서 AI 기능을 만들 때는 먼저 이런 질문을 해야 한다.

“AI가 서비스 안에서 어떤 역할을 하는가?”

AI가 사용자와 직접 대화하는가?
AI가 관리자 업무를 보조하는가?
AI가 내부 데이터를 분류하는가?
AI가 자동으로 시스템 작업을 수행하는가?

역할에 따라 설계 방식이 달라진다.

이 장에서는 AI 기능을 실제 서비스에 붙일 때 자주 사용하는 구조를 살펴본다.

2. AI 기능을 붙이는 대표적인 방식

AI 기능을 서비스에 붙이는 방식은 크게 네 가지로 나눠볼 수 있다.

1. 단순 API 호출형
2. 백엔드 중계형
3. 비동기 작업 큐형
4. 사람 검토 후 반영형

각 방식은 적합한 상황이 다르다.

처음 테스트할 때는 단순 API 호출형으로 시작할 수 있다.

하지만 실제 운영 서비스에서는 대부분 백엔드 중계형 또는 비동기 작업 큐형이 필요하다.

특히 고객 데이터, 내부 문서, 결제 정보, 운영 로그를 다루는 경우에는 AI API를 직접 호출하는 수준으로 끝내면 위험하다.

운영 서비스에서 필요한 것:
- 사용자 인증
- 권한 확인
- 민감 정보 마스킹
- 요청 제한
- 비용 추적
- 응답 검증
- 실패 처리
- 로그 관리

즉, AI 기능은 “AI API를 호출하는 코드”만으로 완성되지 않는다.

AI API 호출 전후에 들어가는 서비스 로직이 훨씬 중요하다.

3. 단순 API 호출형 구조

가장 단순한 방식은 사용자의 요청을 받아 바로 AI API를 호출하는 구조다.

사용자
→ 우리 서버
→ AI API
→ 우리 서버
→ 사용자

예를 들어 관리자 페이지에서 “요약하기” 버튼을 누르면,
서버가 고객 문의 원문을 AI API로 보내고,
AI가 만든 요약을 바로 반환하는 방식이다.

관리자:
고객 문의 요약 버튼 클릭

백엔드:
문의 원문 조회
→ AI API 호출
→ 요약 결과 반환

프론트엔드:
요약 결과 표시

이 방식은 구현이 쉽다.

기능이 단순하고, 입력 데이터가 짧고, 응답 시간이 크게 문제 되지 않는 경우에 사용할 수 있다.

예를 들어 다음 기능은 단순 API 호출형으로 시작해볼 수 있다.

- 짧은 고객 문의 요약
- 관리자 메모 문장 다듬기
- 짧은 공지문 초안 생성
- 간단한 번역 보정
- 코드 설명 요청

하지만 단순 구조에는 한계가 있다.

AI 응답이 오래 걸리면 사용자가 기다려야 한다.
AI API가 실패하면 요청도 실패한다.
요청량이 많아지면 비용이 빠르게 증가할 수 있다.

또 AI API 호출 전후의 통제 장치가 부족하면 보안 문제가 생길 수 있다.

주의할 점:
- 민감 정보가 그대로 전송될 수 있다.
- 실패 시 사용자 경험이 나빠질 수 있다.
- 비용 제한이 없으면 과금이 증가할 수 있다.
- 응답 검증 없이 화면에 노출될 수 있다.

단순 API 호출형은 PoC나 내부 테스트에는 좋다.

하지만 운영 서비스에 적용할 때는 백엔드 중계 계층을 두고 통제하는 구조로 발전시키는 것이 좋다.

PoC는 Proof of Concept의 약자다.
본격 개발 전에 “이 방식이 실제로 가능한지” 작게 검증하는 단계를 말한다.

4. 백엔드 중계형 구조

운영 서비스에서 가장 기본이 되는 구조는 백엔드 중계형이다.

백엔드가 AI API 호출을 직접 관리하는 방식이다.

프론트엔드
→ 백엔드 API
→ AI 호출 모듈
→ AI API
→ AI 호출 모듈
→ 백엔드 API
→ 프론트엔드

이 구조에서는 프론트엔드가 AI API를 직접 호출하지 않는다.

프론트엔드는 우리 백엔드만 호출한다.
AI API Key는 백엔드에만 존재한다.

좋지 않은 방식:
브라우저 → AI API 직접 호출

좋은 방식:
브라우저 → 우리 백엔드 → AI API

프론트엔드에서 AI API를 직접 호출하면 API Key가 노출될 수 있다.
사용자가 브라우저 개발자 도구에서 API Key를 확인할 수 있기 때문이다.

따라서 AI API 호출은 반드시 백엔드에서 처리하는 것이 기본이다.

백엔드 중계형 구조에서는 다음 작업을 한곳에서 처리할 수 있다.

- 사용자 인증 확인
- 권한 확인
- 입력값 검증
- 민감 정보 마스킹
- 프롬프트 템플릿 적용
- AI 모델 선택
- AI API 호출
- 응답 검증
- 사용량 기록
- 실패 처리

예를 들어 고객 문의 요약 기능이라면 백엔드 흐름은 다음과 같다.

1. 관리자 인증 확인
2. 문의 조회 권한 확인
3. 고객 문의 원문 조회
4. 개인정보 마스킹
5. 요약 프롬프트 생성
6. AI API 호출
7. 응답 길이와 금칙어 검증
8. 요약 결과 반환
9. 토큰 사용량 기록

이 구조는 단순 API 호출형보다 복잡하다.

하지만 실제 서비스에서는 훨씬 안전하다.

AI 기능이 하나뿐이라면 간단한 모듈로 시작해도 된다.
AI 기능이 늘어나면 AI Gateway 같은 공통 계층으로 분리할 수 있다.

AI Gateway는 여러 AI 호출을 한곳에서 관리하는 계층이다.
모델 선택, 비용 추적, 프롬프트 관리, 에러 처리, 보안 정책을 공통으로 적용하기 좋다.

5. 비동기 작업 큐형 구조

AI 작업 중에는 시간이 오래 걸리는 작업이 있다.

예를 들어 다음과 같은 작업이다.

- 긴 회의록 요약
- 수백 개 고객 문의 일괄 분류
- 대량 리뷰 감성 분석
- 여러 문서 기반 보고서 생성
- 하루치 로그 분석
- 긴 영상 자막 후처리

이런 작업을 사용자의 HTTP 요청 안에서 바로 처리하면 문제가 생긴다.

응답 시간이 너무 길어질 수 있다.
브라우저나 서버 timeout이 발생할 수 있다.
사용자가 화면을 닫으면 작업 상태를 잃을 수 있다.

이럴 때는 비동기 작업 큐 구조를 사용한다.

사용자
→ 작업 요청
→ 백엔드가 작업 생성
→ 큐에 작업 등록
→ 워커가 AI 작업 처리
→ 결과 저장
→ 사용자에게 완료 상태 표시

흐름을 조금 더 자세히 보면 다음과 같다.

1. 사용자가 긴 문서 요약 요청
2. 백엔드는 즉시 job_id 반환
3. 요약 작업을 큐에 등록
4. 워커가 큐에서 작업을 가져옴
5. 워커가 AI API 호출
6. 결과를 DB에 저장
7. 프론트엔드는 job_id로 상태 조회
8. 완료되면 결과 표시

이 방식은 오래 걸리는 작업에 적합하다.

사용자는 요청 후 바로 화면에서 다른 작업을 할 수 있다.
서버는 긴 작업을 안정적으로 처리할 수 있다.

비동기 작업 큐형에 적합한 기능:
- 대량 데이터 처리
- 긴 문서 요약
- 영상/음성 후처리
- 야간 배치 분석
- 보고서 자동 생성
- 실패 시 재처리가 필요한 작업

구조는 다음과 같이 표현할 수 있다.

[사용자]
   ↓ 작업 요청
[백엔드 API]
   ↓ 작업 등록
[Queue]
   ↓ 작업 소비
[Worker]
   ↓ AI API 호출
[AI API]
   ↓ 결과 반환
[Worker]
   ↓ 결과 저장
[DB]
   ↓ 상태 조회
[프론트엔드]

여기서 Queue는 작업 대기열이다.

작업을 바로 처리하지 않고 줄 세워두는 역할을 한다.

큐는 작업을 순서대로 쌓아두는 대기열이다.
오래 걸리는 작업을 백그라운드에서 안정적으로 처리할 때 자주 사용한다.

6. 사람 검토 후 반영형 구조

AI가 만든 결과를 바로 사용자에게 노출하거나 시스템에 반영하면 위험한 경우가 있다.

예를 들어 다음 작업은 사람이 검토하는 것이 좋다.

- 고객에게 보낼 답변 생성
- 공지문 작성
- 약관이나 정책 문서 초안
- 장애 원인 보고서
- 결제/정산 관련 판단
- 계정 제재 사유 작성
- 법률 또는 개인정보 관련 안내

AI는 그럴듯한 문장을 만들 수 있지만,
회사 정책과 다른 내용을 만들 수 있고,
확인되지 않은 내용을 단정할 수도 있다.

그래서 중요한 업무에서는 AI 결과를 바로 반영하지 않고,
사람이 검토한 뒤 최종 적용하는 구조를 사용한다.

AI 결과 생성
→ 임시 저장
→ 담당자 검토
→ 수정
→ 승인
→ 최종 반영

예를 들어 고객 문의 답변 초안 기능을 생각해보자.

1. 상담원이 고객 문의를 연다.
2. “AI 답변 초안 생성” 버튼을 누른다.
3. AI가 답변 초안을 만든다.
4. 상담원이 내용을 확인하고 수정한다.
5. 상담원이 직접 발송한다.

이 구조에서는 AI가 고객에게 직접 답변하지 않는다.

AI는 상담원의 업무를 보조할 뿐이다.

이 방식은 안전하다.

장점:
- AI 오류를 사람이 걸러낼 수 있다.
- 회사 정책과 맞게 수정할 수 있다.
- 민감한 표현을 조정할 수 있다.
- 책임 있는 업무에 적용하기 쉽다.

관리자용 기능에서도 비슷하게 사용할 수 있다.

예를 들어 AI가 제재 사유를 초안으로 작성하더라도,
운영자가 검토 후 최종 저장하는 방식이 안전하다.

AI:
“반복적인 욕설 및 타인 비방으로 인해 이용 제한 대상입니다.”

운영자:
정책 기준과 실제 로그를 확인
→ 표현 수정
→ 최종 제재 사유 저장

AI가 자동으로 실행하는 범위가 넓어질수록 위험도도 커진다.

처음에는 “AI 초안 + 사람 검토” 구조로 시작하는 것이 좋다.

Human-in-the-loop는 AI 결과를 사람이 검토하거나 승인하는 구조를 말한다.
중요한 의사결정이나 고객 노출 결과에는 이 방식이 안전하다.

7. 관리자 도구에 AI 붙이기

AI 기능은 사용자 서비스보다 관리자 도구에 먼저 적용하기 좋다.

이유는 간단하다.

관리자 도구는 내부 사용자가 쓰기 때문에 통제하기 쉽다.
AI가 조금 부족한 결과를 만들더라도 사람이 확인하고 수정할 수 있다.
사용자에게 직접 노출되는 위험도 낮다.

예를 들어 관리자 도구에 다음 기능을 붙일 수 있다.

- 고객 문의 요약
- 신고 내용 요약
- 채팅 로그 요약
- 회원 활동 이력 정리
- 장애 메모 정리
- 운영자 메모 문장 다듬기
- 답변 초안 생성
- 엑셀 데이터 설명

관리자 도구에 AI를 붙일 때는 “업무 시간을 줄이는 기능”부터 시작하는 것이 좋다.

예를 들어 고객 문의 요약 기능을 보자.

기존에는 상담원이 긴 문의 내용을 모두 읽어야 한다.

고객 문의 원문:
어제 밤에 하트를 충전했는데 결제 문자는 왔고 카드 승인도 됐는데
서비스에서는 충전이 안 되어 있고 방송방에서 후원하려고 했는데 안 됐습니다.
확인 부탁드립니다.

AI 요약은 다음처럼 만들 수 있다.

요약:
고객은 하트 충전 결제 승인 문자는 받았지만,
서비스 내 충전 내역이 반영되지 않았다고 문의했습니다.

상담원은 원문을 모두 읽기 전에 핵심을 빠르게 파악할 수 있다.

하지만 AI 요약만 보고 처리하면 안 된다.

화면에서는 원문과 AI 요약을 함께 보여주는 것이 좋다.

[원문]
고객 문의 전체 내용

[AI 요약]
충전 결제는 승인되었으나 서비스 내 하트가 반영되지 않았다는 문의

[상담원 메모]
상담원이 직접 작성

관리자 도구 AI 기능에서는 다음 원칙이 중요하다.

- AI 결과는 보조 정보로 표시한다.
- 원문을 함께 확인할 수 있게 한다.
- AI 결과를 수정할 수 있게 한다.
- 누가 AI 기능을 사용했는지 로그를 남긴다.
- 민감 정보는 마스킹한다.

관리자 도구는 AI 도입의 좋은 시작점이다.

고객에게 직접 영향을 주기 전에 내부 업무에서 효과를 검증할 수 있기 때문이다.

8. 사용자 서비스에 AI 붙이기

사용자 서비스에 AI를 붙일 때는 더 신중해야 한다.

사용자가 직접 AI 결과를 보거나,
AI 결과가 사용자 행동에 영향을 줄 수 있기 때문이다.

예를 들어 다음 기능들이 있다.

- 사용자용 AI 챗봇
- 자동 번역
- 댓글 또는 채팅 문장 추천
- 프로필 소개글 생성
- 방송 제목 추천
- 콘텐츠 신고 자동 분류
- 개인화 추천 문구

사용자에게 직접 노출되는 AI 기능은 다음을 고려해야 한다.

- 잘못된 답변을 했을 때 피해가 있는가?
- 불쾌하거나 부적절한 표현이 나올 수 있는가?
- 개인정보가 노출될 가능성이 있는가?
- 사용자가 AI 답변을 공식 답변으로 오해할 수 있는가?
- 악용 가능성이 있는가?

예를 들어 사용자용 고객지원 챗봇이 있다고 해보자.

AI가 환불 가능하다고 잘못 안내하면 문제가 된다.

AI:
해당 결제는 환불 가능합니다.

실제 정책:
특정 조건에서는 환불 불가

이런 경우 고객 불만이 커질 수 있다.

그래서 사용자 서비스 AI는 처음부터 완전 자동화하기보다 제한된 범위에서 시작하는 것이 좋다.

안전한 시작 방식:
- FAQ 기반 답변만 제공
- 정책 문서 근거가 있는 답변만 제공
- 확실하지 않으면 상담원 연결
- 결제, 환불, 제재 같은 민감한 판단은 자동 처리하지 않음

사용자에게 보여줄 안내도 필요하다.

AI 답변은 안내를 돕기 위한 참고용입니다.
정확한 처리가 필요한 문의는 고객센터를 통해 확인해주세요.

AI 답변의 표현도 조심해야 한다.

피해야 할 표현:
- 무조건 가능합니다.
- 반드시 처리됩니다.
- 환불됩니다.
- 계정이 복구됩니다.

더 안전한 표현:
- 확인 후 안내가 필요합니다.
- 조건에 따라 처리 가능 여부가 달라질 수 있습니다.
- 고객센터를 통해 추가 확인이 필요합니다.

사용자 서비스에 AI를 붙일 때는 기능보다 안전장치가 먼저다.

9. AI 기능에서 권한 확인은 필수다

AI 기능을 붙일 때 자주 놓치는 것이 권한이다.

AI는 사용자가 요청한 내용을 바탕으로 답변한다.

하지만 AI가 접근할 수 있는 데이터는 반드시 서버에서 제한해야 한다.

예를 들어 관리자가 이렇게 요청했다고 하자.

회원 A의 결제 내역을 요약해줘.

이때 중요한 것은 AI가 요약을 잘하는지가 아니다.

먼저 확인해야 할 것은 이 관리자가 회원 A의 결제 내역을 볼 권한이 있는지다.

1. 관리자 인증 확인
2. 결제 내역 조회 권한 확인
3. 대상 회원 접근 가능 여부 확인
4. 데이터 조회
5. 필요한 정보만 AI에 전달
6. 요약 결과 반환

권한 확인 없이 AI에게 데이터를 넘기면 문제가 생길 수 있다.

위험한 구조:
사용자 요청
→ AI가 필요한 데이터를 알아서 조회
→ 결과 반환

안전한 구조:
서버가 권한 확인
→ 허용된 데이터만 조회
→ AI는 허용된 데이터 안에서만 답변

AI는 권한 시스템을 대신할 수 없다.

권한 판단은 반드시 서비스 서버가 해야 한다.

특히 RAG나 MCP처럼 AI가 외부 도구와 연결되는 구조에서는 더 중요하다.

AI가 문서를 검색하거나 DB를 조회할 수 있다면,
사용자 권한에 따라 접근 가능한 범위를 제한해야 한다.

권한 적용 예시:
- 운영팀은 고객 문의 문서만 접근 가능
- 개발팀은 기술 문서 접근 가능
- 재무팀은 정산 문서 접근 가능
- 일반 관리자는 개인정보 상세 조회 불가
- 슈퍼 관리자만 엑셀 다운로드 가능

AI 기능을 만들 때는 항상 이 질문을 해야 한다.

“이 사용자가 이 데이터를 AI에게 보내도 되는가?”

이 질문에 답하지 못하면 AI 기능을 열면 안 된다.

10. 민감 정보는 AI 호출 전에 처리해야 한다

AI 기능은 데이터를 입력으로 사용한다.

그 데이터 안에는 민감 정보가 들어 있을 수 있다.

예를 들어 고객 문의에는 다음 정보가 포함될 수 있다.

- 이름
- 이메일
- 전화번호
- 결제 정보
- 계좌 정보
- 주소
- 주민등록번호
- 상담 내용

운영 로그에는 다음 정보가 들어갈 수 있다.

- Access Token
- Session ID
- API Key
- 내부 IP
- DB 접속 정보
- 사용자 식별자

AI API에 이런 정보를 그대로 보내면 위험하다.

따라서 AI 호출 전 마스킹 또는 제거가 필요하다.

원문:
홍길동입니다. 이메일은 hong@example.com이고,
전화번호는 010-1234-5678입니다.

마스킹 후:
[NAME]입니다. 이메일은 [EMAIL]이고,
전화번호는 [PHONE]입니다.

마스킹은 완벽하지 않을 수 있다.

그래도 기본적인 개인정보와 인증 정보는 반드시 처리해야 한다.

마스킹 대상:
- 이메일
- 전화번호
- 주민등록번호
- 카드번호
- 계좌번호
- Access Token
- API Key
- 비밀번호
- 세션 값

예를 들어 간단한 마스킹 흐름은 다음과 같다.

사용자 입력 또는 원문 데이터
→ 개인정보 패턴 탐지
→ 민감 정보 마스킹
→ AI 프롬프트 생성
→ AI API 호출

중요한 점은 AI에게 “개인정보를 숨겨줘”라고 맡기는 것이 아니라,
AI API 호출 전에 서버에서 먼저 처리해야 한다는 것이다.

좋지 않은 방식:
개인정보가 포함된 원문을 AI에게 보낸 뒤,
AI에게 개인정보를 제외하고 요약하라고 요청

좋은 방식:
서버에서 개인정보를 먼저 마스킹한 뒤,
마스킹된 내용을 AI에게 전달

AI는 보안 필터가 아니다.

민감 정보 보호는 서비스 서버의 책임이다.

11. AI 응답은 검증 후 사용해야 한다

AI 기능을 서비스에 붙일 때는 입력만 중요한 것이 아니다.

AI가 만든 응답도 검증해야 한다.

예를 들어 AI가 고객 문의를 분류한다고 해보자.

{
  "category": "payment",
  "priority": "high",
  "summary": "하트 충전 후 반영되지 않음"
}

이 응답은 정상처럼 보인다.

하지만 실제 운영 코드에서는 다음을 확인해야 한다.

- category가 허용된 값인가?
- priority가 허용된 값인가?
- summary가 너무 길지 않은가?
- summary에 개인정보가 포함되어 있지 않은가?
- JSON 형식이 올바른가?

AI 응답은 항상 예측한 형식으로 온다고 보장할 수 없다.

다음처럼 올 수도 있다.

이 문의는 결제 관련 문의입니다.

{
  "category": "payment",
  "priority": "high",
  "summary": "하트 충전 후 반영되지 않음"
}

또는 허용하지 않은 값이 들어올 수 있다.

{
  "category": "heart_charge_problem",
  "priority": "urgent",
  "summary": "하트 충전 문제"
}

이런 값은 사람이 보기에는 이해되지만,
프로그램에서는 문제가 될 수 있다.

따라서 AI 응답을 서비스 로직에 사용하려면 스키마 검증이 필요하다.

AI 응답
→ JSON 파싱
→ 필수 필드 확인
→ 허용된 값 확인
→ 길이 제한 확인
→ 민감 정보 포함 여부 확인
→ 통과 시 사용
→ 실패 시 재요청 또는 기본 처리

AI 응답을 사용자에게 바로 보여주는 경우에도 검증이 필요하다.

검증할 항목:
- 부적절한 표현이 없는가?
- 내부 정보가 포함되어 있지 않은가?
- 확인되지 않은 내용을 단정하지 않았는가?
- 너무 길거나 공격적인 표현은 없는가?

AI 응답은 결과물이 아니라 입력값처럼 다뤄야 한다.

외부에서 들어온 데이터처럼 검증하고 사용해야 한다.

스키마 검증은 데이터가 정해진 구조와 값 범위를 지키는지 확인하는 과정이다.
AI 응답을 JSON으로 받을 때 특히 중요하다.

12. AI 기능은 실패할 수 있다고 가정해야 한다

AI API는 실패할 수 있다.

그리고 AI 기능은 일반 API보다 실패 유형이 다양하다.

- AI API 장애
- 응답 지연
- 요청 제한 초과
- 토큰 한도 초과
- 응답 형식 오류
- 부적절한 답변 생성
- JSON 파싱 실패
- 모델 변경으로 인한 품질 저하

그래서 AI 기능은 실패를 전제로 설계해야 한다.

예를 들어 고객 문의 요약 기능이 실패했다고 해보자.

이때 전체 상담 화면이 멈추면 안 된다.

나쁜 처리:
AI 요약 실패
→ 상담 화면 오류
→ 상담원이 원문도 볼 수 없음

좋은 처리:
AI 요약 실패
→ “요약을 생성하지 못했습니다” 표시
→ 원문은 정상 표시
→ 재시도 버튼 제공

AI 기능은 대부분 보조 기능으로 시작하는 것이 좋다.

AI가 실패해도 핵심 업무는 계속 가능해야 한다.

AI 기능 실패 시 원칙:
- 핵심 서비스는 계속 동작해야 한다.
- 사용자에게 이해 가능한 메시지를 보여줘야 한다.
- 운영자가 원인을 추적할 수 있어야 한다.
- 필요하면 재시도할 수 있어야 한다.
- 실패가 반복되면 알림을 받을 수 있어야 한다.

예를 들어 관리자용 AI 요약 기능은 실패해도 원문 조회는 가능해야 한다.

AI 번역 기능이 실패해도 원문 메시지는 보여야 한다.

AI 코드 리뷰가 실패해도 PR 생성은 막지 않는 것이 좋다.

AI는 강력하지만 외부 의존성이다.

따라서 실패해도 서비스 전체가 멈추지 않게 설계해야 한다.

13. AI 기능의 결과를 저장할 것인가

AI가 만든 결과를 저장할지 말지도 중요한 설계 포인트다.

예를 들어 고객 문의 요약 결과를 매번 새로 생성할 수도 있고,
한 번 생성한 요약을 DB에 저장해둘 수도 있다.

방식 1:
요청할 때마다 AI 요약 생성

방식 2:
처음 한 번 AI 요약 생성 후 저장

각 방식에는 장단점이 있다.

예를 들어 고객 문의 원문은 보통 작성 후 크게 바뀌지 않는다.

이 경우 AI 요약 결과를 저장해두면 좋다.

고객 문의 상세 진입
→ 요약이 없으면 AI 생성
→ 요약 저장
→ 다음 조회부터 저장된 요약 표시

반면 실시간 채팅 요약이나 최신 로그 분석은 매번 새로 생성해야 할 수 있다.

AI 결과를 저장할 때는 다음 정보도 함께 저장하면 좋다.

- AI 결과
- 사용한 모델명
- 프롬프트 버전
- 생성 시간
- 생성한 사용자 또는 시스템
- 입력 데이터 기준 시점
- 토큰 사용량

이 정보를 저장하면 나중에 품질 문제가 생겼을 때 추적할 수 있다.

“왜 이 요약이 이렇게 나왔지?”
→ 어떤 모델을 썼는지 확인
→ 어떤 프롬프트 버전이었는지 확인
→ 언제 생성됐는지 확인

AI 결과도 서비스 데이터다.

저장 여부, 갱신 기준, 삭제 기준을 정해야 한다.

14. AI 기능의 비용을 제한하는 방법

AI 기능은 사용량이 늘수록 비용이 증가한다.

그래서 처음부터 비용 제한 장치를 넣는 것이 좋다.

비용을 줄이는 방법은 여러 가지가 있다.

- 입력 데이터 길이 제한
- 출력 길이 제한
- 사용자별 요청 횟수 제한
- 기능별 월 사용량 제한
- 결과 캐싱
- 저렴한 모델과 고성능 모델 분리
- 긴 문서는 필요한 부분만 전달

예를 들어 고객 문의 요약 기능에서는 입력 길이를 제한할 수 있다.

문의 원문이 너무 길면:
- 앞부분과 최근 답변만 사용
- 또는 상담 스레드를 먼저 요약한 뒤 다시 요약

출력도 제한할 수 있다.

요약은 3문장 이내로 작성해줘.

또는 관리자별 사용량 제한을 둘 수 있다.

일반 관리자:
하루 100회 요약 가능

슈퍼 관리자:
하루 1,000회 요약 가능

캐싱도 중요하다.

같은 문의에 대해 같은 요약을 반복 생성할 필요는 없다.

요약 결과가 이미 있으면:
저장된 요약 표시

요약 결과가 없으면:
AI 호출 후 저장

모델을 나눠 쓰는 것도 비용 절감에 효과적이다.

간단한 요약:
저렴하고 빠른 모델

복잡한 분석:
고성능 모델

민감 정보 포함:
로컬 모델 또는 내부망 처리

AI 비용은 기능 출시 후에야 문제가 되는 경우가 많다.

따라서 처음부터 사용량과 비용을 기록해야 한다.

기록할 정보:
- 기능명
- 사용자 ID
- 모델명
- 입력 토큰
- 출력 토큰
- 요청 시간
- 성공 여부

비용은 나중에 통제하는 것보다 처음부터 구조를 넣는 편이 훨씬 쉽다.

15. AI 기능을 화면에 보여주는 방식

AI 결과를 화면에 어떻게 보여줄지도 중요하다.

AI가 만든 결과를 일반 데이터와 똑같이 보여주면 사용자가 공식 결과로 오해할 수 있다.

예를 들어 AI가 고객 문의를 요약했다고 하자.

요약:
고객은 하트 충전 후 금액이 반영되지 않았다고 문의했습니다.

이 요약은 실제 원문을 압축한 결과다.

AI가 일부 내용을 놓쳤을 수 있다.

그래서 화면에서는 AI 결과임을 표시하는 것이 좋다.

[AI 요약]
고객은 하트 충전 후 금액이 반영되지 않았다고 문의했습니다.

※ AI 요약은 참고용입니다. 처리 전 원문을 확인해주세요.

AI 답변의 신뢰도를 구분해서 보여줄 수도 있다.

장애 분석 기능이라면 다음처럼 나누는 것이 좋다.

## 확인된 사실
- 14:05부터 API 응답 지연 발생
- Redis timeout 로그 증가

## AI 추정
- Redis 응답 지연 또는 특정 API 트래픽 집중 가능성

## 추가 확인 필요
- Redis Slowlog
- 배포 이력
- 서버 리소스 지표

사용자는 “확정된 사실”과 “AI 추정”을 구분해서 볼 수 있다.

고객 답변 초안이라면 수정 가능한 형태로 보여주는 것이 좋다.

[AI 답변 초안]
고객님, 불편을 드려 죄송합니다...

[수정 후 발송]
상담원이 직접 수정 가능

AI 결과 UI에서는 다음을 고려해야 한다.

- AI 결과임을 표시할 것인가?
- 원문을 함께 보여줄 것인가?
- 사용자가 수정할 수 있는가?
- 확정/추정/제안을 구분할 것인가?
- AI 결과를 다시 생성할 수 있는가?
- 생성 이력을 남길 것인가?

AI 기능은 백엔드 로직만큼 UI 표현도 중요하다.

사용자가 AI 결과의 성격을 오해하지 않게 해야 한다.

16. AI 기능 출시 전 체크리스트

AI 기능을 서비스에 붙이기 전에는 반드시 점검해야 할 항목이 있다.

아래 체크리스트는 대부분의 AI 기능에 공통으로 적용할 수 있다.

16.1 기능 관점

- AI 기능의 목적이 명확한가?
- AI가 실패해도 핵심 기능은 동작하는가?
- 사용자에게 AI 결과가 어떻게 표시되는가?
- 재시도 또는 다시 생성 기능이 필요한가?
- AI 결과를 저장할 것인가?

16.2 보안 관점

- AI 호출 전에 민감 정보를 제거하거나 마스킹하는가?
- 사용자가 접근 가능한 데이터만 AI에 전달하는가?
- API Key가 프론트엔드에 노출되지 않는가?
- 로그에 개인정보나 인증 정보가 남지 않는가?
- 관리자 권한별 접근 제어가 적용되는가?

16.3 비용 관점

- 사용자별 사용량 제한이 있는가?
- 입력 길이와 출력 길이를 제한하는가?
- 토큰 사용량을 기록하는가?
- 반복 요청을 캐싱할 수 있는가?
- 비용이 높은 모델을 제한적으로 사용하는가?

16.4 품질 관점

- AI 응답 형식을 검증하는가?
- 잘못된 응답이 나왔을 때 처리 방법이 있는가?
- 사람이 검토해야 하는 결과인가?
- 답변 품질을 테스트한 샘플 데이터가 있는가?
- 모델 또는 프롬프트 변경 시 비교할 기준이 있는가?

16.5 운영 관점

- AI API 실패 시 fallback이 있는가?
- timeout 설정이 있는가?
- 에러 로그가 남는가?
- 응답 시간이 모니터링되는가?
- 장애 알림 기준이 있는가?
- 프롬프트 버전을 관리하는가?

AI 기능은 처음에는 작은 기능처럼 보일 수 있다.

하지만 서비스에 붙는 순간 운영 기능이 된다.

따라서 출시 전 체크리스트를 반드시 거치는 것이 좋다.

17. AI 기능을 단계적으로 확장하는 방법

AI 기능은 작게 시작해서 확장하는 것이 좋다.

처음부터 완전 자동화나 에이전트 구조로 가면 위험하다.

추천하는 단계는 다음과 같다.

1단계: 내부 보조 기능
- 관리자용 요약
- 문장 다듬기
- 운영 메모 정리

2단계: 사람 검토 후 반영
- 고객 답변 초안
- 공지문 초안
- 신고 처리 사유 초안

3단계: 제한된 자동화
- 문의 유형 자동 분류
- 우선순위 자동 태깅
- 반복 문서 자동 생성

4단계: 사용자 대상 기능
- 사용자용 챗봇
- 자동 번역
- 개인화 추천 문구

5단계: 시스템 연동
- RAG 기반 문서 검색
- Jira/GitHub 연동
- MCP 기반 도구 호출

처음부터 사용자에게 직접 노출되는 기능을 만들기보다,
관리자 도구나 내부 업무 보조 기능부터 시작하는 것이 안전하다.

이렇게 하면 AI 품질과 비용을 내부에서 먼저 검증할 수 있다.

내부 적용
→ 품질 확인
→ 비용 확인
→ 보안 검토
→ 운영 기준 수립
→ 사용자 기능으로 확장

AI 기능은 기술보다 운영 경험이 중요하다.

작게 붙이고, 실제 사용 데이터를 보고, 점진적으로 확장하는 방식이 가장 안전하다.

18. 정리

AI 기능을 서비스에 붙이는 방식은 다양하다.

간단한 요약처럼 요청 즉시 처리할 수 있는 기능도 있고,
긴 문서 분석처럼 비동기 작업 큐가 필요한 기능도 있다.
고객 답변이나 공지문처럼 사람이 검토한 뒤 반영해야 하는 기능도 있다.

AI 기능을 만들 때 중요한 것은 단순히 AI API를 호출하는 것이 아니다.

- 어떤 데이터가 AI에 들어가는가
- 누가 이 기능을 사용할 수 있는가
- AI 결과를 바로 사용할 것인가
- 사람이 검토해야 하는가
- 실패하면 어떻게 처리할 것인가
- 비용은 어떻게 제한할 것인가
- 로그와 개인정보는 어떻게 보호할 것인가

이런 질문에 답할 수 있어야 한다.

AI 기능은 처음에는 내부 관리자 도구부터 시작하는 것이 좋다.

고객 문의 요약, 신고 내용 정리, 운영 메모 정리처럼
사람이 검토할 수 있는 보조 기능부터 적용하면 위험을 줄일 수 있다.

이후 품질과 비용이 검증되면 사용자 서비스, 자동화, RAG, MCP로 확장할 수 있다.

이 장에서 기억해야 할 핵심은 하나다.

AI 기능을 서비스에 붙인다는 것은 AI API를 호출하는 것이 아니라,
AI가 만든 결과를 안전하게 업무 흐름 안에 넣는 것이다.

10장 핵심 요약